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A DECOMPOSITION ARCHITECTURE FOR AN MCU 

RELATED APPLICATIONS 

This application is a continuation-in-part of United States Patent Application Serial 
Number 09/708,898, filed November 8, 2000, the contents of which are incorporated herein 
by reference. The present application further claims the benefit of priority from United States 
Provisional Application Serial No. 60/164,298 filed November 08, 1999, the contents of 
which are incorporated herein by reference. 

FIELD OF THE INVENTION 

This invention relates generally to multimedia communications, and more 
specifically, to a system and method for decomposing a multipoint multimedia 
communication system to control unit and process unit. 

BACKGROUND 

As the geographical domain in which companies conduct business continues to 
expand, the traffic of multimedia teleconferencing overloads multimedia communication 
central nodes. In the current market, most multipoint multimedia calls are scheduled in 
advance through companies that own multipoint control units (MCUs). An MCU provides 
the capability for three or more terminals and gateways to participate in a multipoint 
conference. If a company owns more than one MCU, it has more flexibility in hosting 
multimedia conferences. However, each MCU must be operated independently from the 
other MCUs in setting up and controlling multimedia conferences. Additionally, the capacity 
of each MCU is limited to multimedia conferences controlled by the corresponding MCU. 
Because each MCU is a single entity that handles both the call signaling and the media 
processing of the conference, the resources of the multiple MCUs cannot be combined to 
promote more efficient scheduling. 
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As the business of multimedia conferences continues to expand, more and more 
standards have been written for multimedia conferences, such as H.320, H.321, H.324, and H. 
323 SIP. Those standards handle the call signaling and call control differently, yet use the 
same multimedia data standards such as H.261, H.263, MPEG, G.711, and T.120. The 
increasing number of multimedia conferences and standards drive the need for an MCU 
technology that is able to operate efficiently in a site utilizing a plurality of MCUs, which 
may share resources in order to increase the amount of traffic via the site. Furthermore, there 
is a need for technology easily adaptable to varying standards and increasing capacity. 

The ITU and the IETF have defined decomposition architecture for a multimedia 
gateway, which comprises of a multimedia gateway control unit (MGC), a multimedia 
process unit (MG), and the intermediary communication protocol, Megaco/H.248. The 
MCU, as defined in the H.323 standard, comprises of a multipoint control unit (MC) and a 
multipoint processor (MP). The MC is an H.323 entity on the network that provides the 
control of three or more terminals participating in a multipoint conference. The MC may also 
connect two terminals in a point-to-point conference, which may later develop into a 
multipoint conference. The MC provides capability negotiation with all terminals to achieve 
common levels of communications, and may also control conference resources. However, the 
MC does not perform mixing or switching of audio, video and data. 

The Multipoint Processor (MP) is an H.323 entity on the network providing the 
centralized processing of audio, video, and/or data streams in a multipoint conference. The 
MP provides the mixing, switching, or other processing of media streams under the control of 
the MC. The MP may process a single media stream or multiple media streams depending on 
the type of conference supported. The ITU has not defined the communication protocol 
between those two units in H.323, or a Decomposition MCU (DMCU) for other standards 
then H.323. One difficulty in operating the DMCU with other standards, such as H.320, is 
that signaling, control and media are multiplexed. 

The decomposition architecture offers better utilization of resources, for one MC can 
control plurality of MPs, and a conference can share resources in a plurality of units etc. 
Also, an operator can upgrade its site by adding the appropriate units MP or MC according to 
it's the operator's needs. Those units can be from different vendors. In case of new versions 
or new standards the operator can update only the relevant unit MP or MC. 
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The MC functionality can be part of a general Media Gateway Controller (MGC). 
The MC can be considered as an MGC. Therefore, it is evident that there is a need for a 
DMCU that can work with plurality of endpoints supporting different standards. 

SUMMARY OF THE INVENTION 

The present invention provides a general DMCU that is not limited to H.323 and can 
also work for other standards like but not limited to H.320; H.321; H.324; and SIP. The 
DMCU comprises of a MC and a MP. The MC handles the call signaling and control while 
the MP handles the media streams. In cases where signaling, control and media are 
multiplexed (H.320; H.321 etc.) the MP will demultiplex/multiplex the streams and then uses 
signaling, tunneling or backhauling to send and receive control or signaling messages to and 
from the MC. The DMCU will address the different conferencing models as described in 
H.323, including centralized, decentralized and hybrid multipoint conference. In the case of 
decentralized or hybrid conference, a virtual MP may exist, even as part of the MC, and will 
support the media handling for the MC. In centralized conference all participating terminals 
communicate in a point-to-point fashion with an MCU. The terminals transmit their control, 
audio, video, and/or data streams to the MCU. The MC within the MCU centrally manages 
the conference. The MP within the MCU processes the audio, video, and/or data streams and 
returns the processed streams to each terminal. 

A decentralized multipoint conference is one in which the participating terminals 
multicast their audio and video to all other participating terminals. The terminals are 
responsible for: 

a) summing the received audio streams; and 

b) selecting one or more of the received video streams for display. No audio or video 
MP is required in this case. The terminals communicate on their H.225, RAS and 
H.245 Control Channels with an MC that manages the conference. The data stream 
is still centrally processed by the MCU. 

There are two types of hybrid multipoint conferences. A hybrid multipoint 
centralized audio conference is one in which terminals multicast their video to other 
participating terminals and unicast their audio to the MP for mixing. The MP returns a mixed 
audio stream to each terminal. A hybrid multipoint centralized video conference is one in 
which terminals multicast their audio to other participating terminals and unicast their video 
to the MP for switching or mixing. The MP returns a video stream to each terminal. 
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According to H.248, the logical entities in MP that can be controlled by the MC 
include terminations and contexts. A termination is a logical entity on a MP that sources 
and/or sinks media and/or control streams. A termination is described by a number of 
characterizing properties, which are grouped in a set of descriptors that are included in 
commands. A descriptor is a syntactic element that groups related properties. For instance, 
the properties of a media flow on the MP can be set by the MC by including the appropriate 
descriptor in a command. Terminations have unique identities (termination IDs), assigned by 
the MP manager at the time of their creation. 

Terminations representing physical entities have a semi-permanent existence. For 
example, a termination representing a TDM channel might exist for as long as it is 
provisioned in the DMCU. Terminations representing ephemeral information flows, such as 
RTP flows, would usually exist only for the duration of their use. Ephemeral terminations are 
created by means of an Add command. They are destroyed by means of a Subtract command. 
In contrast, when a physical termination is added to or subtracted from a context, it is taken 
from or to the null Context, respectively. 

Terminations may have signals applied to them. Signals are MP generated media 
streams such as tones and announcements. Terminations may be programmed to detect 
Events, the occurrence of which can trigger notification messages to the MC, or action by the 
MP. Statistics may be accumulated on a termination. Statistics are reported to the MC upon 
request (by means of the AuditValue command,) and when the termination is removed from a 
call. 

The protocol between the two units, MC and MP, can be used to create new 
terminations and to modify property values of existing terminations. These modifications 
include the possibility of adding or removing events and/or signals. An MC can only 
release/modify terminations and the resources that the termination represents that it has 
previously seized via, e.g., the Add command. Example terminations include 
MUX/DEMUX, ISDN ports, and audio mixers. 

A context is an association between numbers of terminations. The context can 
describe the topology (who hears/sees whom) and the media mixing and/or switching 
parameters if more than two terminations are involved in the association. A special context 
called the null context contains terminations that are not associated to any other termination. 
Terminations in the null context can have their parameters examined or modified, and may 
have events detected on them. 
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In general, an Add command is used to add terminations to contexts. If the MC does 
not specify an existing context to which the termination is to be added, the MP creates a new 
context. A termination may be removed from a context with a subtract command, and a 
termination may be moved from one context to another with a Move command. A 
termination SHALL exist in only one context at a time. The maximum number of 
terminations in a context is an MP property. DMCU that support multipoint conferences 
might allow three or more terminations per context. 

The attributes of contexts are ContextID and the topology (who hears/sees whom). 
An exemplary context can be a videoconference of 3 participants: one is using an H.323 
endpoint and two are using H.320 endpoint with bit rate that is different from the first one. 
This context includes the following terminations: three networks I/F ports, one RTP, two 
MUXes, an audio mixer and a video mixer. The present invention implements a DMCU by 
using the connection model and protocol that is described in H.248. The present invention 
allows communication and resources sharing between plurality of MCs and MPs. 

The MC includes the part of the call state that handles the call signaling and call 
control of the MPs that are connected to it. The MC can be a software program residing in a 
General Media Gateway controller. Other objects, features, and advantages of the present 
invention will become apparent upon reading the following detailed description of the 
embodiments of the invention, when taken in conjunction with the accompanying drawings 
and appended claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a system diagram that illustrates an exemplary operator site implementing 
various embodiments of the present invention. 

Fig. 2 is a system diagram that illustrates another exemplary operator site. 

Fig. 3 is a functional block diagram of an exemplary MC. 

Fig. 4 is a functional block diagram of an exemplary MP. 

Fig. 5 is a functional block diagram of an exemplary context. 

Fig. 6 is a flow diagram illustrating the steps involved in an exemplary embodiment of 
the present invention during the conference. 
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DETAILED DESCRIPTION 

Referring now to the drawings, in which like numerals refer to like parts throughout 
the several views, exemplary embodiments of the present invention are described. 

Fig. 1 is a system diagram that illustrates an exemplary operator site 100 
implementing various embodiments of the present invention. The site 100 may include one 
or more DMCUs: (110a; 120a); (110b; 120b) and (110c; 120c). An exemplary DMCU 
comprises of one MC (110a; 110b; 110c) and one MP (120a; 120b; 120c) respectively. 
Although three DMCUs are illustrated, the present invention is not limited to a particular 
number of DMCUs and the presented configuration is intended to be illustrative of an 
exemplary configuration. An MC can control one or more MPs. The connection between the 
MC and MP that compose a DMCU is based on H.248/Megaco over IP it may be over an 
Intranet 130, Internet LAN, or direct connection. The MCs and the MPs may be co-located or 
geographically dispersed. 

In an exemplary system, each DMCU supports connections with various types of 
terminals (not shown) including, but not limited to, H.321 H.324 and H.320 terminals. 
Those terminals are connected to Switched Circuit Networks (SCN) 140 like but not limited 
to PSTN and ISDN. The exemplary system 100 also supports H.323 and SIP terminals (not 
shown) that are connected to packet switch network ISO, including but not limited to, local 
area networks, the Internet or an Intranet. The connections to the terminals are illustrated as 
network clouds (140 and 150). Connection cloud 140 is connected to the MCs via signaling 
and control line 143 and to the MPs via the media line 147. Connection cloud 150 is 
connected to the MCs via signaling and control line 153 and to the MPs via the media line 
157. 

Lines 143 and 153 represent an exemplary functional architecture of signaling and 
control connection. The signaling and control can also be physically connected to the MP. 
The MP transfers those signals via tunneling or backhaul to the appropriate MC. Those 
skilled in the art will appreciate that other terminal protocols and other networks could be 
used in alternative embodiments. 

A terminal is an endpoint on a network, capable of providing real-time, two-way 
multimedia communication; audio and/or visual communication and/or data with other 
terminals or an MCU. The information communicated between the terminals and/or the 
MCU includes, but is not limited to, control signals, indicators, audio, moving color video 
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pictures and data. A terminal may provide speech only, speech and data, speech and video, or 
speech, data and video. In another exemplary configuration of a DMCU an MC may control 
more than one MP via the same IP network 130. 

Fig. 2 is a system diagram that illustrates another exemplary operator site 1000 that 
using another exemplary configuration of a DMCU, in which more than one MC, via the 
same IP network, 130 may control a single MP. In this configuration each physical MP 
(120a; 120b; 120c) may be divided into several logical MPs. For instance MP 120a may be 
divided into Logical MPs 120aa; 120ab and 120ac and a different MC (110a; 110b; 110c) 
may control each logical MP respectively. For example, MC 110b controls Logical MP 
120ab. 

Another exemplary configuration of a DMCU (not shown in the drawings) utilizes the 
architecture of a Virtual MCU (VMCU). In this configuration one of the MCs becomes a 
Decomposed VMCU (DVMCU) and uses similar methods to control the other MCs and MPs 
as the methods that the VMCU uses to control the MCUs. The communication between the 
DVMCU the MPs and the other MCs is done over an IP network. Those skilled in the art 
will appreciate that an operator site may comprise of any of the above configurations of a 
DMCU or any combination of those configurations. 

Fig. 3 is a functional block diagram of an exemplary MC 110. The MC 110 is a 
platform independent system solution for controlling one or more MPs (120a ? 120b, 120c). 
The MC may be a physical unit or a software program residing in a Media Gateway 
Controller (MGC) or a software program residing in a conventional MCU. 

In an exemplary embodiment of the present invention, the MC 110 includes several 
modules that are controlled by an MC Management Module (MMM) 330. The modules that 
the MC includes, like but are not limited to: SS7 Module 310; H.225, H.245 & RAS Module 
320; H.323 Stack 325; SIP Module and stack 345; Conference Management Module (CMM) 
335 and H.248 Module 340. The CMM 335 may be a part of the MC or it can be an external 
module that resides in an external general computer system. 

The MC 110 is connected, in both directions, to the H.225; H.245 & RAS Module 
320; SIP Module 345 H.248 Module 340 and the SS7 Module 310. The MC communicates 
with H.323 Endpoint , which are connected to Packet switched network via H.225; H.245 & 
RAS Module 320. Said module 320 comprises of three sub modules for processing the 
H.323 components: H.225 sub module which processes the call signaling, H.245 which 
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processes the call control information and the RAS sub module for processing the 
registration, admission and status component. The information is then processed by the 
H.323 Stack 325 and the processed information is transferred to the MMM 330. Each MC 
may include plurality of H.225; H.245 & RAS Modules 320 one per each switched packet 
networks that the MC is connected to. 

The MC communicates with SIP endpoints, which are connected to the packet 
switch network via the SIP module 345 for call signaling and call control. The information is 
processed by the SIP stack and is transferred to MMM 330. Users, which are connected over 
SCN 5 communicate with the MC 110 via the MP 120 or via Signaling Gateway 160 through 
additional H.248 Module 142 or via a signaling protocol like SS7 through SS7 Module 310. 
In communication with endpoints, which use such as like H.320, H.321, and H.324, the MP 
120 MUX/DEMUX, the signaling and control components from the multiplexed stream, 
transcode them into H.248/Megaco protocol and transfer them to the MC 110 via H.248 
Module 340. The SS7 module 310 conveys the Non-Facility Associated Signaling (NFAS) 
SCN signaling to the MMM 330. This module provides the flexibility to conserve SS7 code 
points and allows the SS7 switch to serve multiple DMCUs. 

The MMM 330 manages the resources (terminations) of the MPs 120 that are 
controlled by the MC 110 and the events that occur. The MMM 330 may use an internal or 
external CMM 335 which comprises a plurality of multimedia conferencing management 
tools including but not limited to a conference reservation manager, a conference manager, a 
reports manager, a system administrator tool, and databases. 

The CMM 335 is connected to the external world via an IP connection 350. The 
external connection enables management communication with the customers, including but 
not limited to, conference reservation and requests for reports. The CMM 335 acts as the 
interface between the customer and the MC and manages the conference reservations and 
reports while the MMM 330 controls the ongoing conferences (contexts). 

The Conferences Reservation Manager accepts requests for multimedia session 
reservations via an IP connection 350 and uses the reservation parameters to verify that it can 
be accepted. The reservation parameters include but are not limited to the number and types 
of terminals, line-speed, type of audio algorithm, start-time, end-time, video algorithm and 
the type of network. The Conferences Reservation Manager then stores the reservation record 
in the database. If the session has to start immediately, the Conferences Reservation Manager 
passes the information to the MMM 330. The Conferences Manager starts a session when the 
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session's time to start arrives. The Conferences Manager loads the session onto the target MP 
via the MMM 330 and H.248 module 340 and gets status information from all of the MPs 
concerning ongoing sessions. 

The Reporting Manager builds reports which may include length of time 
terminations were used, particular terminations used for a specific session, and percentage of 
terminations used during a specified time period. The reports are built upon the receipt of a 
report request from the site operator via an IP connection 350. The System Administrator 
serves as an input tool for the MC parameters. The MC parameter may include, but are not 
limited to, the maximum number of MPs controlled by the MC, and neighbor MCs. In an 
exemplary embodiment of the present invention, the databases store data pertaining to 
reservations, users, and any other data required for the operation of the DMCU. The database 
can be an external database such as a database using LDAP or ILS. 

The MMM 330 keeps the information concerning the MPs terminations i.e. audio 
terminations, video terminations, etc. When the MMM 330 gets a request to initiate a 
conference from CMM 335 it allocates the appropriate terminations to a context that 
represents the requested conference. An exemplary method for initiate a conference is 
describing below in conjunction with Figure 6. 

The MMM 330, based on the available terminations of an MP, also calculates 
terminations availability for future contexts reservations. The MMM 330 may receive 
messages, such as call start and call terminate, from the MP and stores the messages in a 
database. The MMM 330 provides for capability negotiation with all terminals to achiever 
common levels of communications based on the signaling and controls signals that it receives 
from the various terminals and MPs via H.323 Stack 325 and/or H.248 Module 340 and with 
cooperation with CMM 335. The MMM 330 may also control conference resources and may 
start and terminate the call signaling and control. The MMM 330 decides which MP 120 will 
handle a context (conference) and the terminations in said MP that will be in said context. 
Then MMM 330 manages the termination and streams in the context according to the current 
status of the conference. 

Fig. 4 is a functional block diagram of an exemplary MP 120. The MP 120 provides 
media processing, mixing, switching, transcoding or other processing of media streams 
(Audio, Video and Data) under the control of the MC. The MP may process a single media 
stream or multiple media streams depending on the type of conference supported. 
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In the cases where signaling, control and media are multiplexed (H.320; H.321 H.324 
etc.) the MP will demultiplex the streams, and to transfer the call control and/or the call 
signaling messages to the MC 110, using signaling, tunneling or backhaul. 

In an exemplary embodiment of the present invention, a functional MP 120 includes 
several modules, including but not limited to a plurality of switch packet network Interface 
(SPNI) 445; H.248 Module 447; SCN Interface 450 plurality of active context 410, and a 
Bank of Available Terminations (BOAT) 420. An MP Management Module (MPMM) 430 
controls those modules. The BOAT 420 comprises of several groups of terminations 461 to 
466, each group includes plurality of terminations from the same type. A termination can be 
a physical entity or a logical entity that is composed from physical entities allocated to said 
termination by the MPMM when the termination is added to a context. 

Although three active contexts 410, three SCN Interfaces 450, three SPNI 445 and 
three terminations in a group are illustrated, the present invention is not limited to a particular 
number and the presented configuration is intended to be illustrative of an exemplary 
configuration. 

Some of the units and terminations that compose the MP 120 are units that exist in a 
typical MCU such as Accord MGC 100. The DMCU manages those units in novel method. 
The unique modules of an MP are MPMM 430 and H.248 Module 340. The MP may be a 
physical unit or a software adaptation of a conventional MCU. The MP may be also a 
Software program running on a general computer. 

The MP 120 receives and transmits operational control to and from the MC 110 via 
H.248 Module 447. Media communication with the users is done directly through the 
appropriate context 410. Detail description of an exemplary context is done below in 
reference to Fig. 5. 

Although call set up, call control, call signaling and call management are done by the 
MC 110, the MP 120 can tunnel them between the SCN 140 or the packet switch network 
150 users and the MC 110. The MP includes plurality of SCN Interface Modules 450. Each 
Module 450 accepts a SCN dial in number. In the event that one of the connections is 
involving in a current context then its SCN Interface Module 450 becomes a part of the 
context 410. 

Bonding termination 462 handles the bonding of the N ISDN 64kbit channels to one 
call. More information about bonding can be found in standard ISO/IEC 13871 in website: 
www.iso.ch . H.221 MUX termination 463 is handling the multiplexing and demultiplex of 
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the H.221 stream, and receives the bit rate of the call, the structure of the H.221 stream and 
demultiplexes the stream to audio, video, data and control streams. The control information 
is transferred to MPMM 430 that may use part of the information and transfer the 
information, which is required by the MC 110, to H.248 Module 447, 

H.248 Module 447 transmits this information to the appropriate MC using 
H.248/Megaco/IP protocol. The connection between the MP and the MC can be by direct 
connection or via IP network, such as Intranet, Internet; LAN etc. If an endpoint is already 
connected to an active conference via a context 410, then the SCN Interface module 450 
becomes part of said context 410 and transfers the video, audio and data to the appropriate 
video mixer termination 465; audio mixer termination 464 and data termination 466, which 
belong to the same context. The H.221 MUX 463 also handles H.221 channel association. 

The media processing resources of an exemplary MP 120 includes Audio Mixer 
Terminations 464; Video Mixer Terminations 465 and Data Terminations 466. The Audio 
Terminations (AMT) 464 handles the audio mixing. The mixer will accept audio streams 
from all participants and will mix them. The mixing options will be either the N loudest 
speakers or N specific streams. The audio mixer signals the stream ID of the loudest speaker 
and the Ids of the mixed streams. 

When an RTP or H.221 MUX termination is modified or added, the audio mixer is 
modified with the stream ID and the audio codec of the stream. 

Video Mix Termination (VMT) 465 can be of one of four types, not shown in the 
drawing. Video switch termination is conducting a video switching conference. In this 
conference type, one of the incoming video streams is sent to all the other participants. The 
selected stream can be the video stream of the active speaker who will receive the previous 
speaker stream or the MC can decide the displayed stream for each participant. The voice 
activated switching can be managed automatically by the MPMM 430, or by the MC 110. In 
this type of conference all video streams have the same parameters (line rate, frame rate, 
algorithm). 

Video mixing termination conducts a video mix session that mixes N out of M 
streams. The MC 110 defines the incoming stream IDs for the termination, the layout and if 
to switch the content of a window according to the active speaker and the selected streams 
(participants) to be mixed for each participant. The video stream parameters can be different 
for each stream. Video softmix termination is a video mix session that mixes 4 incoming 
streams that have the same parameters (example mixing four H.261 QCIF stream to one 
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H.261 CIF outgoing stream). Transcode termination is similar to video switch but the MC 
-110 defines the video mode of the termination and allows it to transcode video streams that 
have different parameters. In the event that the conference includes data the Data 
Termination (DT) 466 process the data protocols like T.120 etc. and transfers back the 
processed data . 

The RTP Termination 461 handles the different media packet streams. It receives 
them from the SPNI 445 and separates them to four different streams as instructed by the 
MC. Control information, if received in the MP, is transferred to the MC 110 via H.248 
module 447. Data is transferred to DT 466, video is transferred to VMT 465, and audio to 
AMT 464. On the outgoing direction, it receives the streams from the DT 465, VMT 466 
and the AMT 464 and send them to the remote terminal Stream synchronization like lip 
synch can be done in the RTP 461 or in the VMT 466 and AMT 464 according to MC 
commands. The physical unit of a termination like but not limited to an AMT 464, a VMT 
465, a DT 466, H.221 MUX 463, and RTP Termination 461, which may be a modified 
physical unit belonging to a common MCU or a common Audio Bridge, with some 
modifications such as the mapping of the physical unit into logical terminations. 

There are several levels of control in managing Multimedia Multipoint Conferences. 
For example, the MC 110 interfaces with the client by accepting requests, making 
reservations, setting up calls, terminating calls. The MP 120 may be part of this activity, but 
as a channel between the MC and the customer. 

The MC 110 also manages the resources of the MP 120. The MC 110 selects the 
appropriate MP 120 and the appropriate type of terminations in said MP that will be involved 
in the conference, and also defines the type of conference and the streams that need to be 
present to the customer. The MPMM 430 receives the resource allocation, the type of 
conference and the streams that need to be present to the customer, from the MC 110. Based 
on this information the MPMM 130 selects the exact physical resource. Then the MPMM 
430 creates the terminations and the context according to the command from the MC 110. 
The VMT 465, the AMT, and the DT 466 handle the stream topology. The MPMM 430 
transmits to the MC the ID number of the selected terminations and status and indications 
about the ongoing conferences. 

Real time management; the MPMM 430 manages the conference context. The 
MPMM 430 creates a Virtual context Manager (VCM) per conference. The VCM manages 
the conference. It receives indications and statuses from the terminations. In case of a 
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conference that dynamically replaces speakers based on the loudest speaker the VCM changes 
the speaker based on the received indications. 

Figure 5 is illustrating an exemplary context, Context N 410. The context is an entity 
that has been generated by the DMCU for the period of the conference. It is initiated by the 
MC 110, it is constructed by the MPMM 430 and its real time management is done by VCM 
510. At the end of the session the MC clears the context and returns the terminations of the 
context to BOAT 420. 

The exemplary context represents a conference of four endpoints with the following 
exemplary parameters. Endpoint 1 (EP1), not shown in the drawing, is connected to SCN 
140 using H.320 protocol and video compression standard H.26L Endpoint 2 (EP2), not 
shown in the drawing, is connected to SCN 140 using H.320 protocol and video compression 
standard H.263. Endpoint 3 (EP3) s not shown in the drawing, is connected to the Internet 150 
with H.323 protocol and video compression standard H.263. Endpoint 4 (EP4),not shown in 
the drawing, is connected to the Internet 150 with H.323 protocol and video compression 
standard H.261. 

The required properties for the conference are: All endpoints are Video Audio and 
Data Endpoints. The conference type Video Transcoding meaning that all the participant sees 
the current loudest speaker while the speaker sees the previous one and the video streams are 
transcoded to accommodate the different endpoints. 

Based on the above needs the MC 110 request from the MP 120 to create a Context 
with the following terminations: two Bonding terminations 462; two H.221 MUX 
terminations 463; two RTP Terminations 461; an AMT 464; a VMT 465 and a DT 466. The 
VMT will be of type Transcoding Video Termination. 

The MPMM 430 selects the exact terminations from the BOAT 420 and defines the 
streams among those terminations. For the current example the MP selects and defines the 
following termination and connections: 

An AMT 464f is a common audio mixer that can mix the audio of at least four inputs. 
The AMT 464f can analyze the inputs identify the loudest speaker and send indication about 
the Identification of the loudest one. 

A VMT 465c is a video transcoding unit it can be implemented by common 
transcoding methods like using four decoders, four encoders (one channel per 
each endpoint) and a shared video bus. 
A DT 466 that can handles data protocols like T.120. 
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Two Bonding terminations 462a and 462b. 
Two H.221 MUX terminations 463a and 463b. 
And two RTP Terminations 461a and 461b. 

The MPMM 430 defines the topology of the exemplary context as follow: 
The media stream to and from EP1 is done via Bonding termination 462a and H.221 MUX 
463a. From unit 463 a the Audio stream is transferred to the first channel of AMT 464f. The 
video stream is transferred to Channel number 1 of VMT 465c. The decoder and the encoder 
of channel 1 are adjusted to fit the needs of EP1. The output of the encoder of channel 1 is 
transferred to unit 463a. The data is transferred to DT 466f. 

The media stream of EP2 is using similar path but via units 462b, 463b, the second 
channel in AMT 464f and the second channel of VMT 465c respectively. The media stream 
to and from EP3 (not shown) is done via RTP Termination 461a. From unit 461a the Audio 
stream is transferred to the 3rd channel of AMT 464f . The video stream is transferred to the 
3 rd Channel of VMT 465c. The decoder and the encoder of channel 3 are adjusted to fit the 
needs of EP3. The output of the video encoder of channel 3 is transferred to unit 461a. The 
data is transferred to DT 466f. 

The media stream of EP4 is using similar path but via units 461b, the 4 th channel in 
AMT 464f and the 4 th channel of VMT 465c and the 4 th channel of DT 466f respectively. 
VCM 510 receives indications from all the units. Among these indications it gets indication 
from AMT 465f about the loudest speaker. When the loudest speaker is changed the VCM 
510 routes the output of the video encoder of the new loudest endpoint to the other three 
endpoints while the video to the new loudest speaker remains the same, (the video of the 
previous speaker). 

The VCM 510 informs the MC about replacing the speaker as well as any other 
changes in the status of the conference. In another scenario the VCM 510 only informing the 
MC about the loudest speaker and the MC instruct the VCM 510 to change routing. The 
VCM is not changing the routing automatically, 

Fig. 6 is a flow diagram illustrating the steps involved in an exemplary embodiment of 
the present invention during a conference. During the initiation step 610 the MP 120 
connects to the MC and informs the MC 110 which termination it supports and what are the 
capacities and algorithms supported. This is done by sending a service change from the MP 
and the MC will do audit values. The MC 110 keeps track of all MPs connected to it and the 
capacity of each MP. 
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When the MC 110 receives from the Conferencing Service Manager, CMM 
335, the conference parameters (number of participants, dial out number etc.). In step 612 the 
MC creates the conference context on the MP 120. The MC 110 adds in step 614 the selected 
type of video mixer and audio mixer terminations to the conference; the selected terminations 
fit the definitions of the conference. The MP based on this information creates in step 616 the 
context with the added terminations, (VMT, AMT and the DT), and allocates the needed MP 
physical resource. It returns the identifiers of the context and terminations to the MC and the 
MC registers the conference in its database. 

Depending on the type of Endpoint, the MC allocates the resources that are related to 
the Endpoint. The MC starts a loop on all the Endpoints. In step 620 the MC checks the type 
of the Endpoint. If the endpoint is using protocol H.320 the MC moves to step 622 and adds 
H.221 MUX Termination 463 and in cases that it needs Bonding the MC adds also a 
Termination 462. 

The H.221 MUX Termination 463 or the Bonding termination 462, if bonding is 
needed, dials the user and exchange capabilities, step 624. The H.221 MUX Termination 463 
updates the MC with the results of the negotiation. Another way to exchange parameters can 
be by the MC, which dials via a signaling gateway and using the SS7 Module 310. 

The MC exchange capabilities with the endpoint and establish the communication 
mode. In H.320 the H.221 MUX termination will do the actual protocol but the MC will do 
decisions. If the Endpoint is H.323 endpoint, the MC moves to step 626, adds an RTP 
Termination 461 to the context on the MP 120. The MP 120 sends the port ID number to the 
MC. 

In step 628 the MC dials the user. The H.323 protocol stack is part of the MC and the 
MC exchanges capabilities with the endpoint. Based on the results of the capabilities 
negotiations the MC in step 630 decides on the conference mode and updates the 
Terminations in the context. The MC updates the RTP 461 or H.221 MUX Termination 463 
and the video and audio mixer terminations with the right codec information. 

The MC in step 632 instruct the MP to opens the channels for communication and 
returns to step 620 for the next Endpoint until the MC adds all the endpoints. During the 
conference both logical units, the MP 120 and the MC 110, controls the conference. The MC 
in step 634 may receive H.245 commands or tunneled H.320 BAS commands that may affect 
the conference context. For example getting a video fast update command from the remote 
end may trigger a command to the video mixer termination. In parallel the MP, step 636, in 
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the case of voice activated switching may switch active speaker and notify the MC about the 
switching, the MC decide which method to use. In step 640 the MC identifying the end of 
conference manages the conference tear down process. It will terminate calls delete the 
terminations and context. 

In the description and claims of the present application, each of the verbs, "comprise" 
"include" and "have", and conjugates thereof, are used to indicate that the object or objects of 
the verb are not necessarily a complete listing of members, components, elements or parts of 
the subject or subjects of the verb. 

The present invention has been described using detailed descriptions of embodiments 
thereof that are provided by way of example and are not intended to limit the scope of the 
invention. The described embodiments comprise different features, not all of which are 
required in all embodiments of the invention. Some embodiments of the present invention 
utilize only some of the features or possible combinations of the features. Variations of 
embodiments of the present invention that are described and embodiments of the present 
invention comprising different combinations of features noted in the described embodiments 
will occur to persons of the art. The scope of the invention is limited only by the following 
claims. 
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